Skip to content

fix(rs_lib): restore stripped deploy.include for workspace-member paths#99

Open
crowlbot wants to merge 1 commit into
mainfrom
fix/deploy-include-workspace-member
Open

fix(rs_lib): restore stripped deploy.include for workspace-member paths#99
crowlbot wants to merge 1 commit into
mainfrom
fix/deploy-include-workspace-member

Conversation

@crowlbot
Copy link
Copy Markdown

Fixes #90.

Root cause

`deno_config` 0.97's `WorkspaceDirectory::to_deploy_config` calls `exclude_includes_with_member_for_base_for_root`, which strips any user-supplied `deploy.include` entry whose base path falls inside a workspace member directory. That strip is correct when the member has its own competing `deploy` block, but it's over-eager for the common case where the member has no deploy block: the user explicitly listed those paths, and the strip leaves the file collector with an empty include set and zero uploaded files. From the bug report, with this config:

```jsonc
{
"workspace": ["./packages/backend"],
"deploy": {
"org": "myorg",
"app": "myapp",
"include": ["./packages/backend/**"]
}
}
```

the resolver logs:

```
[rs_lib] deploy config: include=Some(PathOrPatternSet([])), exclude=PathOrPatternSet([])
[rs_lib] collect_files(...) -> 0 file(s): []
```

Fix

After calling `workspace_dir.to_deploy_config(pattern)`, re-read the raw `deploy.include` from whichever deno.json owns the `deploy` block (member preferred, root fallback) and re-append any entries that the upstream strip removed. Patterns are compared by their resolved `base_path()` so we don't duplicate entries that genuinely survived the strip.

If/when `deno_config` upstream learns to only strip when the member has its own deploy block, this patch can be dropped.

Test plan

  • `cargo test` in `rs_lib/` — 3 passing (the existing workspace-root regression + two new ones below).
    • `workspace_root_deploy_include_targeting_member_glob` — the glob case from the report; asserts both `main.ts` and `extra.txt` appear.
    • `workspace_root_deploy_include_targeting_member_file` — explicit-file case; asserts `main.ts` is included and unlisted siblings (`extra.txt`) are not.
  • `deno task build` regenerates `lib/rs_lib.{js,wasm,d.ts}`.
  • `deno fmt` / `deno lint` / `deno check` clean.
  • `deno test -A tests/create.test.ts` — 17/17 pass.

Repro confirmation

The new tests fail before the patch (`expected .../main.ts in deploy files; got []`) and pass after.

🤖 Generated with Claude Code

Fixes #90.

When `deno deploy` is run from a Deno workspace root with a root-level
`deploy.include` entry that points at a workspace member, the upstream
`deno_config::WorkspaceDirectory::to_deploy_config` calls
`exclude_includes_with_member_for_base_for_root`, which strips any
include whose base path falls inside a workspace member directory. That
strip is correct when the member has its own competing `deploy` block,
but it's over-eager for the common case where the member has no deploy
block — the user explicitly asked for those files, and the strip leaves
us with an empty include set and zero uploaded files.

Patch in rs_lib: after calling `workspace_dir.to_deploy_config(pattern)`,
re-read the raw `deploy.include` from whichever deno.json owns the
`deploy` block (member preferred, root fallback) and re-append any
entries that the upstream strip removed. Patterns are compared by their
resolved `base_path()`, so we don't duplicate entries that genuinely
survived the strip.

Adds two regression tests in `rs_lib/src/lib.rs`:
- Workspace-root deploy with `include: ["./packages/backend/**"]` — the
  glob case from the bug report.
- Workspace-root deploy with `include: ["./packages/backend/main.ts"]`
  — the explicit-file case, which also verifies that adjacent files in
  the member directory are *not* picked up when not listed.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

deploy.include from workspace root collects no workspace member files

1 participant